Please address the comments from this code review:

## Overall Comments
- The entropy span for `Key` is recreated with a hard-coded length (`stackalloc byte[22]`) and inline logic; consider extracting this into a small helper that derives the exact byte count from `Encoding.UTF8.GetByteCount(Key)` to avoid magic numbers and potential truncation/padding issues.
- Now that new keys are stored as version 2 with CNG DPAPI while old ones remain at version 1, you may want to consider an inline migration path (e.g., re-protecting v1 keys as v2 upon load) to avoid persisting mixed key formats over time.

## Individual Comments

### Comment 1
<location path="PCL.Core/Utils/Secret/EncryptHelper.cs" line_range="156-158" />
<code_context>
         {
             var buf = File.ReadAllBytes(keyFile);
             var data = EncryptionData.FromBytes(buf);
+            Span<byte> store = stackalloc byte[22];
+            Key.GetBytes(Encoding.UTF8, store);
+            var space = (ReadOnlySpan<byte>)store;
             return data.Version switch
             {
</code_context>
<issue_to_address>
**issue (bug_risk):** The stackalloc buffer length likely does not match the actual UTF-8 byte length of `Key`, which can break decryption for existing v1 keys.

Because the stackalloc span is 22 bytes, you’re passing 22 bytes (including an extra 0) as entropy to `ProtectedData.Unprotect`, while v1 keys were protected with a 21-byte `_IdentifyEntropy` buffer. DPAPI treats all entropy bytes as significant, so this off-by-one will prevent decryption of existing v1 keys. Please either use `Encoding.UTF8.GetBytes(Key)` as before, or size the span via `Encoding.UTF8.GetByteCount(Key)` and slice it to the actual number of bytes written from `Key.GetBytes`.
</issue_to_address>

### Comment 2
<location path="PCL.Core/Utils/Secret/EncryptHelper.cs" line_range="162" />
<code_context>
             {
-                1 => ProtectedData.Unprotect(data.Data, _IdentifyEntropy, DataProtectionScope.CurrentUser),
+                1 => ProtectedData.Unprotect(data.Data.AsSpan(), DataProtectionScope.CurrentUser, space),
+                2 => CngProtectedData.Unprotect(data.Data.AsSpan(), CngDataProtectionScope.CurrentUser, space),
                 _ => throw new NotSupportedException("Unsupported key version")
             };
</code_context>
<issue_to_address>
**issue (bug_risk):** Unprotect for v2 uses additional entropy, but Protect for v2 does not, which can cause decryption failures.

For v2, the key is protected without entropy but unprotected with `space` as entropy. If `CngProtectedData` matches DPAPI semantics, the entropy passed to `Unprotect` must be identical to what was used in `Protect`, so adding entropy only at unprotect time will cause decryption to fail. Align the calls by either omitting entropy on unprotect or using the same entropy during protect.
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- The new ReadOnlySpan<char>.GetBytes extension methods currently call ToString(), which defeats the purpose of using spans and adds an allocation; consider using the Encoding.GetBytes(ReadOnlySpan<char>, Span<byte>) overloads directly to avoid intermediate strings and keep this utility truly span-friendly.
- Given the ReadOnlySpan<char>.GetBytes extension is only used for the fixed Key constant, you might simplify by inlining Encoding.UTF8.GetBytes(Key) (or a static cached byte[]), reducing indirection and avoiding introducing a general-purpose extension that may be misused or misunderstood elsewhere.

## Individual Comments

### Comment 1
<location path="PCL.Core/Utils/Secret/EncryptHelper.cs" line_range="159" />
<code_context>
             return data.Version switch
             {
-                1 => ProtectedData.Unprotect(data.Data, _IdentifyEntropy, DataProtectionScope.CurrentUser),
+                1 => ProtectedData.Unprotect(data.Data, DataProtectionScope.CurrentUser, space),
+                2 => CngProtectedData.Unprotect(data.Data, CngDataProtectionScope.CurrentUser, space),
                 _ => throw new NotSupportedException("Unsupported key version")
</code_context>
<issue_to_address>
**issue (bug_risk):** ProtectedData.Unprotect arguments appear to be in the wrong order compared to the standard API.

The original call `ProtectedData.Unprotect(data.Data, _IdentifyEntropy, DataProtectionScope.CurrentUser)` matches the API `(byte[] encryptedData, byte[] optionalEntropy, DataProtectionScope scope)`. The new call `ProtectedData.Unprotect(data.Data, DataProtectionScope.CurrentUser, space)` swaps `optionalEntropy` and `scope`, which will either fail to compile or change behavior. This should be `ProtectedData.Unprotect(data.Data, space, DataProtectionScope.CurrentUser)` instead.
</issue_to_address>

### Comment 2
<location path="PCL.Core/Utils/Exts/StringExtension.cs" line_range="296-300" />
<code_context>
+            return encode.GetBytes(str.ToString());
+        }
+
+        public void GetBytes(Encoding? encode, Span<byte> space)
+        {
+            encode ??= Encoding.UTF8;
+            encode.GetBytes(str, space);
+        }
+    }
</code_context>
<issue_to_address>
**suggestion:** Consider returning the number of bytes written from the span-based GetBytes overload.

This overload currently returns `void`, whereas `Encoding.GetBytes(ReadOnlySpan<char>, Span<byte>)` returns an `int` with the number of bytes written. Returning that `int` here (and optionally renaming `space` to something like `destination`) would give callers a reliable way to know how many bytes in the span are valid.

```suggestion
        public int GetBytes(Encoding? encode = null, Span<byte> destination)
        {
            encode ??= Encoding.UTF8;
            return encode.GetBytes(str, destination);
        }
```
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- The new `Key` field is declared as `readnoly` and uses `"PCL CE Encryption Key".GetBytes()`; this won’t compile as written (typo on `readonly` and `GetBytes` is defined as a `ReadOnlySpan<char>` extension), so either keep the original `Encoding.UTF8.GetBytes` or add a proper `string` extension overload.
- In `_GetKey`, the call `CngProtectedData.Protect(randomKey, CngDataProtectionScope.CurrentUser, space)` references an undefined `space` variable; if you intended to pass the entropy key, this should likely be `Key` (or another explicit parameter) instead.
- The new `ReadOnlySpan<char>` extension `GetBytes(Encoding? encode = null)` calls `str.ToString()` and then encodes it, which defeats the purpose of using spans; consider using the span-based `Encoding.GetBytes(ReadOnlySpan<char>, Span<byte>)` overload (or similar) to avoid the intermediate string allocation.

## Individual Comments

### Comment 1
<location path="PCL.Core/Utils/Secret/EncryptHelper.cs" line_range="16-19" />
<code_context>

 public static class EncryptHelper
 {
+    private static readnoly byte[] Key = "PCL CE Encryption Key".GetBytes();
     public static (IEncryptionProvider Provider, uint Version) DefaultProvider => _DefaultProvider.Value;
     private static readonly Lazy<(IEncryptionProvider Provider, uint Version)> _DefaultProvider = new(_SelectBestEncryption);
</code_context>
<issue_to_address>
**issue (typo):** Typo in `readnoly` will prevent this field from compiling.

Use the `readonly` keyword here; as written, this line won’t compile and the `Key` field won’t be defined correctly.

```suggestion
public static class EncryptHelper
{
    private static readonly byte[] Key = "PCL CE Encryption Key".GetBytes();
    public static (IEncryptionProvider Provider, uint Version) DefaultProvider => _DefaultProvider.Value;
```
</issue_to_address>

### Comment 2
<location path="PCL.Core/Utils/Exts/StringExtension.cs" line_range="290-293" />
<code_context>
+
+    extension(ReadOnlySpan<char> str)
+    {
+        public byte[] GetBytes(Encoding? encode = null)
+        {
+            encode ??= Encoding.UTF8;
+            return encode.GetBytes(str.ToString());
+        }
+
</code_context>
<issue_to_address>
**suggestion (performance):** Avoid allocating an intermediate string when encoding a `ReadOnlySpan<char>`.

`str.ToString()` adds an unnecessary allocation. Where supported, prefer the `Encoding.GetBytes(ReadOnlySpan<char>)` overload for spans. If you need to support older frameworks, consider `GetByteCount` + a rented/pooled buffer to avoid extra allocations in hot paths.

Suggested implementation:

```csharp
        public byte[] GetBytes(Encoding? encode = null)
        {
            encode ??= Encoding.UTF8;
            return encode.GetBytes(str);
        }

```

If this project must target frameworks that do not support `Encoding.GetBytes(ReadOnlySpan<char>)` (e.g., .NET Framework or .NET Standard 2.0), you will need to replace the direct `encode.GetBytes(str)` call with a fallback that:
1. Uses `encode.GetByteCount(str)` to determine the byte count.
2. Allocates or rents a `byte[]` of the required size (e.g., via `ArrayPool<byte>.Shared.Rent` in hot paths).
3. Calls `encode.GetBytes(str, destinationSpan)` to fill the buffer.
4. Returns either the exact-sized array or the rented buffer (trimming/copying if necessary).
You can use `#if` conditionals around the span-based overload to keep compatibility with older targets if needed.
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- The new `Key` entropy value in `EncryptHelper` is stored as a mutable `byte[]`; consider exposing it as a `ReadOnlyMemory<byte>` or returning a new span from a property to avoid accidental mutation of a process-wide crypto constant.
- The new string/`ReadOnlySpan<char>` `GetBytes` helpers introduce a dependency from crypto code to the general string extensions; if these are meant primarily for crypto usage, consider moving them to a more low-level/crypto-focused helper to keep layering clearer.
- For the `ReadOnlySpan<char>.GetBytes(Span<byte> destination, Encoding? encode = null)` extension, it might be helpful to document or wrap the `GetByteCount`/`GetBytes` pattern so callers can easily determine the required buffer size and avoid unexpected `ArgumentException` when the destination span is too small.